Frigjør Ytelse: Et Dypdykk i WebGL Clustered Forward Rendering og Optimalisering av Lysindeksering

I en verden av sanntids 3D-grafikk på nettet, har rendering av tallrike dynamiske lys alltid vært en betydelig ytelsesutfordring. Som utviklere streber vi etter å skape rikere, mer immersive scener, men hver ekstra lyskilde kan eksponentielt øke beregningskostnaden og presse WebGL til sine grenser. Tradisjonelle renderingsteknikker tvinger oss ofte til et vanskelig valg: ofre visuell kvalitet for ytelse, eller akseptere lavere bildefrekvenser. Men hva om det fantes en måte å få det beste fra begge verdener?

Her kommer Clustered Forward Rendering, også kjent som Forward+. Denne kraftige teknikken tilbyr en sofistikert løsning som kombinerer enkelheten og materialfleksibiliteten til tradisjonell forward rendering med lyseffektiviteten til deferred shading. Den lar oss rendere scener med hundrevis, eller til og med tusenvis, av dynamiske lys samtidig som vi opprettholder interaktive bildefrekvenser.

Denne artikkelen gir en omfattende utforskning av Clustered Forward Rendering i en WebGL-kontekst. Vi vil dissekere kjernekonseptene, fra å dele opp view frustum til å fjerne lys (culling), og fokusere intenst på den mest kritiske optimaliseringen: datastrømmen for lysindeksering. Dette er mekanismen som effektivt kommuniserer hvilke lys som påvirker hvilke deler av skjermen fra CPU-en til GPU-ens fragment shader.

Renderingslandskapet: Forward vs. Deferred

For å forstå hvorfor clustered rendering er så effektivt, må vi først forstå begrensningene til metodene som kom før den.

Tradisjonell Forward Rendering

Dette er den mest rett-frem renderingstilnærmingen. For hvert objekt prosesserer vertex shaderen dets hjørnepunkter, og fragment shaderen beregner den endelige fargen for hver piksel. Når det gjelder belysning, går fragment shaderen vanligvis gjennom hvert eneste lys i scenen og akkumulerer dets bidrag. Hovedproblemet er den dårlige skaleringen. Beregningskostnaden er omtrent proporsjonal med (Antall Fragmenter) x (Antall Lys). Med bare noen få dusin lys kan ytelsen stupe, ettersom hver piksel redundant sjekker hvert lys, selv de som er milevis unna eller bak en vegg.

Deferred Shading

Deferred Shading ble utviklet for å løse akkurat dette problemet. Den frikobler geometri fra belysning i en to-pass-prosess:

1. Geometri-pass: Scenens geometri renderes til flere fullskjermsteksturer samlet kjent som G-bufferen. Disse teksturene lagrer data som posisjon, normaler og materialegenskaper (f.eks. albedo, ruhet) for hver piksel.
2. Lys-pass: En fullskjerms-quad tegnes. For hver piksel sampler fragment shaderen G-bufferen for å rekonstruere overflateegenskapene og beregner deretter belysningen. Hovedfordelen er at belysningen kun beregnes én gang per piksel, og det er enkelt å bestemme hvilke lys som påvirker pikselen basert på dens verdensposisjon.

Selv om den er svært effektiv for scener med mange lys, har deferred shading sine egne ulemper, spesielt for WebGL. Den har høye krav til minnebåndbredde på grunn av G-bufferen, sliter med gjennomsiktighet (som krever et separat forward rendering-pass), og kompliserer bruken av anti-aliasing-teknikker som MSAA.

Argumentet for en mellomting: Forward+

Clustered Forward Rendering gir et elegant kompromiss. Den beholder enkelt-pass-naturen og materialfleksibiliteten til forward rendering, men inkluderer et forbehandlingstrinn for å dramatisk redusere antall lysberegninger per fragment. Den unngår den tunge G-bufferen, noe som gjør den mer minnevennlig og kompatibel med gjennomsiktighet og MSAA fra starten av.

Kjernekonsepter i Clustered Forward Rendering

Den sentrale ideen med clustered rendering er å være smartere med hvilke lys vi sjekker. I stedet for at hver piksel sjekker hvert lys, kan vi forhåndsbestemme hvilke lys som er nærme nok til å potensielt påvirke en region av skjermen, og la pikslene i den regionen kun sjekke disse lysene.

Dette oppnås ved å dele kameraets view frustum inn i et 3D-rutenett av mindre volumer kalt klynger (clusters) (eller fliser (tiles)).

Hele prosessen kan deles inn i fire hovedstadier:

• 1. Opprettelse av Klynge-rutenett: Definer og konstruer et 3D-rutenett som deler opp view frustum. Dette rutenettet er fast i view space og beveger seg med kameraet.
• 2. Lystildeling (Culling): For hver klynge i rutenettet, bestem en liste over alle lys hvis innflytelsesvolumer krysser den. Dette er det avgjørende culling-steget.
• 3. Lysindeksering: Dette er vårt fokus. Vi pakker resultatene fra lystildelingssteget inn i en kompakt datastruktur som effektivt kan sendes til GPU-en og leses av fragment shaderen.
• 4. Shading: Under hovedrendering-passet bestemmer fragment shaderen først hvilken klynge den tilhører. Deretter bruker den lysindekseringsdataene til å hente listen over relevante lys for den klyngen og utfører lysberegninger *only* for den lille undergruppen av lys.

Dypdykk: Bygging av Klynge-rutenettet

Grunnlaget for teknikken er et velstrukturert rutenett. Valgene som tas her påvirker både culling-effektivitet og ytelse direkte.

Definere Rutenettdimensjoner

Rutenettet defineres av sin oppløsning langs X-, Y- og Z-aksene (f.eks. 16x9x24 klynger). Valget av dimensjoner er en avveining:

• Høyere Oppløsning (Flere Klynger): Fører til strammere, mer nøyaktig lys-culling. Færre lys vil bli tildelt per klynge, noe som betyr mindre arbeid for fragment shaderen. Det øker imidlertid overheaden for lystildelingssteget på CPU-en og minneavtrykket til klyngedatastrukturene.
• Lavere Oppløsning (Færre Klynger): Reduserer overhead på CPU-siden og i minnet, men resulterer i grovere culling. Hver klynge er større, så den vil krysse flere lys, noe som fører til mer arbeid i fragment shaderen.

En vanlig praksis er å knytte X- og Y-dimensjonene til skjermens sideforhold, for eksempel ved å dele skjermen inn i 16x9 fliser. Z-dimensjonen er ofte den mest kritiske å justere.

Logaritmisk Z-oppdeling: En Kritisk Optimalisering

Hvis vi deler frustumets dybde (Z-aksen) i lineære skiver, støter vi på et problem relatert til perspektivprojeksjon. En stor mengde geometriske detaljer er konsentrert nær kameraet, mens objekter langt unna opptar svært få piksler. En lineær Z-oppdeling ville skape store, upresise klynger nær kameraet (der presisjon er mest nødvendig) og små, sløsende klynger i det fjerne.

Løsningen er logaritmisk (eller eksponentiell) Z-oppdeling. Dette skaper mindre, mer presise klynger nær kameraet og gradvis større klynger lenger unna, noe som justerer klyngefordelingen med måten perspektivprojeksjon fungerer på. Dette sikrer et jevnere antall fragmenter per klynge og fører til mye mer effektiv culling.

En formel for å beregne dybden `z` for den i-te skiven ut av `N` totale skiver, gitt nærplanet `n` og fjernplanet `f`, kan uttrykkes som:

Denne formelen sikrer at forholdet mellom påfølgende skivedybder er konstant, noe som skaper den ønskede eksponentielle fordelingen.

Sakens Kjerne: Lys-culling og Indeksering

Det er her magien skjer. Når rutenettet vårt er definert, må vi finne ut hvilke lys som påvirker hvilke klynger og deretter pakke denne informasjonen for GPU-en. I WebGL utføres denne lys-culling-logikken vanligvis på CPU-en ved hjelp av JavaScript for hver ramme der lys eller kameraet beveger seg.

Kryssingstester mellom Lys og Klynge

Prosessen er konseptuelt enkel: gå gjennom hvert lys og test det for kryssing mot hver klynges avgrensningsvolum. Avgrensningsvolumet for en klynge er i seg selv et frustum. Vanlige tester inkluderer:

• Punktlys: Behandles som sfærer. Testen er en sfære-frustum-kryssing.
• Spotlys: Behandles som kjegler. Testen er en kjegle-frustum-kryssing, som er mer kompleks.
• Retningsbestemte Lys: Disse anses ofte for å påvirke alt, så de håndteres vanligvis separat og er ikke inkludert i culling-prosessen.

Å utføre disse testene effektivt er nøkkelen. Etter dette trinnet har vi en kartlegging, kanskje i en JavaScript-array av arrays, som: clusterLights[clusterId] = [lightId1, lightId2, ...].

Datastrukturutfordringen: Fra CPU til GPU

Hvordan får vi denne lyslisten per klynge til fragment shaderen? Vi kan ikke bare sende en array med variabel lengde. Shaderen trenger en forutsigbar måte å slå opp disse dataene på. Det er her tilnærmingen med en Global Lysliste og en Lysindeksliste kommer inn. Det er en elegant metode for å flate ut vår komplekse datastruktur til GPU-vennlige teksturer.

Vi oppretter to primære datastrukturer:

1. En Klyngeinformasjons-rutenett-tekstur: Dette er en 3D-tekstur (eller en 2D-tekstur som emulerer en 3D-en) der hver texel korresponderer med én klynge i rutenettet vårt. Hver texel lagrer to viktige biter med informasjon:
   • En offset: Dette er startindeksen i vår andre datastruktur (den Globale Lyslisten) der lysene for denne klyngen begynner.
   • En count: Dette er antall lys som påvirker denne klyngen.
2. En Global Lysliste-tekstur: Dette er en enkel 1D-liste (lagret i en 2D-tekstur) som inneholder en sammenhengende sekvens av alle lysindekser for alle klynger.

Visualisere Datastrømmen

La oss forestille oss et enkelt scenario:

• Klynge 0 påvirkes av lys med indekser [5, 12].
• Klynge 1 påvirkes av lys med indekser [8, 5, 20].
• Klynge 2 påvirkes av lys med indeks [7].

Global Lysliste: [5, 12, 8, 5, 20, 7, ...]

Klyngeinformasjons-rutenett:

• Texel for Klynge 0: { offset: 0, count: 2 }
• Texel for Klynge 1: { offset: 2, count: 3 }
• Texel for Klynge 2: { offset: 5, count: 1 }

Implementering i WebGL & GLSL

La oss nå koble konseptene til koden. Implementeringen involverer en JavaScript-del for culling og dataforberedelse, og en GLSL-del for shading.

Dataoverføring til GPU-en (JavaScript)

Etter å ha utført lys-culling på CPU-en, vil du ha dine klyngerutenett-data (offset/count-par) og din globale lysliste. Disse må lastes opp til GPU-en hver ramme.

1. Pakk og Last Opp Klyngedata: Lag en `Float32Array` eller `Uint32Array` for dine klyngedata. Du kan pakke offset og count for hver klynge inn i RG-kanalene i en tekstur. Bruk `gl.texImage2D` for å opprette eller `gl.texSubImage2D` for å oppdatere en tekstur med disse dataene. Dette vil være din Klyngeinformasjons-rutenett-tekstur.
2. Last Opp Global Lysliste: På samme måte, flat ut lysindeksene dine til en `Uint32Array` og last den opp til en annen tekstur.
3. Last Opp Lysegenskaper: Alle lysdata (posisjon, farge, intensitet, radius, osv.) bør lagres i en stor tekstur eller en Uniform Buffer Object (UBO) for raske, indekserte oppslag fra shaderen.

Logikken i Fragment Shaderen (GLSL)

Det er i fragment shaderen ytelsesgevinstene realiseres. Her er den trinnvise logikken:

Trinn 1: Bestem Fragmentets Klyngeindeks

Først må vi vite hvilken klynge det nåværende fragmentet faller inn i. Dette krever dets posisjon i view space.

            
// Uniforms som gir rutenettinformasjon
uniform vec3 u_gridDimensions; // f.eks., vec3(16.0, 9.0, 24.0)
uniform vec2 u_screenDimensions;
uniform float u_nearPlane;
uniform float u_farPlane;

// Funksjon for å hente Z-skive-indeksen fra view-space dybde
float getClusterZIndex(float viewZ) {
  // viewZ er negativ, gjør den positiv
  viewZ = -viewZ;
  // Den inverse av den logaritmiske formelen vi brukte på CPU-en
  float slice = floor(log(viewZ / u_nearPlane) / log(u_farPlane / u_nearPlane) * u_gridDimensions.z);
  return slice;
}

// Hovedlogikk for å hente 3D-klyngeindeksen
vec3 getClusterIndex() {
  // Hent X- og Y-indeks fra skjermkoordinater
  float clusterX = floor(gl_FragCoord.x / u_screenDimensions.x * u_gridDimensions.x);
  float clusterY = floor(gl_FragCoord.y / u_screenDimensions.y * u_gridDimensions.y);
  
  // Hent Z-indeks fra fragmentets view-space Z-posisjon (v_viewPos.z)
  float clusterZ = getClusterZIndex(v_viewPos.z);

  return vec3(clusterX, clusterY, clusterZ);
}

            

              
                Copy
              
            
          

Trinn 2: Hent Klyngedata

Ved hjelp av klyngeindeksen sampler vi vår Klyngeinformasjons-rutenett-tekstur for å få offset og count for dette fragmentets lysliste.

            
uniform sampler2D u_clusterTexture; // Tekstur som lagrer offset og count

// ... i main() ...
vec3 clusterIndex = getClusterIndex();
// Flat ut 3D-indeks til 2D-teksturkoordinat om nødvendig
vec2 clusterTexCoord = ...; 

vec2 lightData = texture2D(u_clusterTexture, clusterTexCoord).rg;
int offset = int(lightData.x);
int count = int(lightData.y);

            

              
                Copy
              
            
          

Trinn 3: Løkke og Akkumuler Belysning

Dette er det siste trinnet. Vi utfører en kort, begrenset løkke. For hver iterasjon henter vi en lysindeks fra den Globale Lyslisten, bruker deretter den indeksen til å hente lysets fulle egenskaper og beregne dets bidrag.

            
uniform sampler2D u_globalLightIndexTexture;
uniform sampler2D u_lightPropertiesTexture; // UBO ville vært bedre

vec3 finalColor = vec3(0.0);

for (int i = 0; i < count; i++) {
  // 1. Hent indeksen til lyset som skal prosesseres
  int lightIndex = int(texture2D(u_globalLightIndexTexture, vec2(float(offset + i), 0.0)).r);

  // 2. Hent lysets egenskaper ved hjelp av denne indeksen
  Light currentLight = getLightProperties(lightIndex, u_lightPropertiesTexture);

  // 3. Beregn dette lysets bidrag
  finalColor += calculateLight(currentLight, surfaceProperties, viewDir);
}

            

              
                Copy
              
            
          

Og det er alt! I stedet for en løkke som kjører hundrevis av ganger, har vi nå en løkke som kanskje kjører 5, 10 eller 30 ganger, avhengig av lystettheten i den spesifikke delen av scenen, noe som fører til en monumental ytelsesforbedring.

Avanserte Optimaliseringer og Fremtidige Betraktninger

• CPU vs. Compute: Den primære flaskehalsen for denne teknikken i WebGL er at lys-culling skjer på CPU-en i JavaScript. Dette er enkelttrådet og krever en datasynkronisering med GPU-en hver ramme. Ankomsten av WebGPU er en 'game-changer'. Dens compute shadere vil tillate at hele prosessen med klyngebygging og lys-culling kan avlastes til GPU-en, noe som gjør den parallell og mange størrelsesordener raskere.
• Minnehåndtering: Vær oppmerksom på minnet som brukes av datastrukturene dine. For et 16x9x24-rutenett (3,456 klynger) og et maks på, si, 64 lys per klynge, kan den globale lyslisten potensielt inneholde 221,184 indekser. Å justere rutenettet og sette et realistisk maksimum for lys per klynge er essensielt.
• Justering av Rutenettet: Det finnes ikke ett magisk tall for rutenettdimensjoner. Den optimale konfigurasjonen avhenger sterkt av scenens innhold, kameraets oppførsel og målgruppens maskinvare. Profilering og eksperimentering med forskjellige rutenettstørrelser er avgjørende for å oppnå topp ytelse.

Konklusjon

Clustered Forward Rendering er mer enn bare en akademisk kuriositet; det er en praktisk og kraftig løsning på et betydelig problem i sanntids webgrafikk. Ved å intelligent dele opp view space og utføre et høyt optimalisert steg for lys-culling og indeksering, bryter den den direkte koblingen mellom antall lys og kostnaden for fragment shaderen.

Selv om den introduserer mer kompleksitet på CPU-siden sammenlignet med tradisjonell forward rendering, er ytelsesgevinsten enorm, noe som muliggjør rikere, mer dynamiske og visuelt overbevisende opplevelser direkte i nettleseren. Kjernen i suksessen ligger i den effektive datastrømmen for lysindeksering – broen som transformerer et komplekst romlig problem til en enkel, begrenset løkke på GPU-en.

Ettersom nettplattformen utvikler seg med teknologier som WebGPU, vil teknikker som Clustered Forward Rendering bare bli mer tilgjengelige og ytelsesdyktige, og ytterligere viske ut grensene mellom native og nettbaserte 3D-applikasjoner.